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TOOL FOR BUILDING DOCUMENTS FOR a given standardized group of transacting parties, to the 

COMMERCE IN TRADING PARTNER exclusion of others. 

NETWORKS AND INTERFACE A good overview of the challenges met by Internet 

DEFINITIONS BASED ON THE commerce development is provided in Tenenbaum, et al., 

DOCUMENTS 5 "£co System: An Internet Commerce Architecture", 

Computer. May 1997. pp. 48-55. 

CONTINUING APPLICATION DATA To open commercial transactions on the Internet, stan- 
dardization of architectural frameworks is desired. Platforms 

This application is a continuation of U.S. patent applica- developed to support such commercial frameworks include 

tion Ser. No. 09/173,858, filed on Oct. 16, 1998, entitled jbm Commerce Point, Microsoft Internet Commerce 

DOCUMENTS FOR COMMERCE IN TRADING PART- Framework, Netscape ONE (Open Network Environment), 

NER NETWORKS AND INTERFACE DEFINITIONS Oracle NCA (Network Computing Architecture), and Sun/ 

BASED ON THE DOCUMENTS. JAVASoft JECF (JAVA Electronic Commerce Framework). 

Hie present application is related to U.S. patent applica- In addition to these proprietary frameworks, program- 

tion Ser. No. 09/173,847, filed on Oct. 16. 1998. now U.S. 15 ™i°g techniques, such as common distributed object model 

Pat. No. 6,226.675 Bl. entitled PARTIQPANT SERVER based on CORBA HOP (Common Object Request Broker 

WHICH PROCESSES DOCUMENTS FOR COMMERCE Architecture Internet ORB Protocol), are being pursued. Use 

IN TRADING PARTNER NETWORKS; and °f common distributed object model is intended to 

rio f . ^ , simplify the migration of enterprise systems to systems 

r. :IT Wli^tion Ser. No 09/173,854, filed on ^^^^ interoperate at the business appUcation level for 

Oct. 16, 1998, now U.S. Pat. No. 6,125,391, entitled MAR- 20 electronic commerce. However, a consumer or business 

KET MAKERS USING DOCUMENTS FOR COM- using one framework is unable to execute transactions on a 

MERGE IN TRADING PARTNER NETWORKS. different framework. This limits the growth of electronic 

commerce systems. 

REFERENCE TO COMP™ Companies implementing one framework wQI have an 

LISTING APPENDIX 25 application programming interface API which is different 

A computer program listing appendix comprising dupli- ^ L° ^^'^ supporting other frameworks. Thus, it is very 

cate copies of a compact disc, named "CMRC1004-8 '''ffi^"" for companies to access each others business 

CPLA." accompanies this application and is incorporated by ^'^'^ ^'i^""' ^^""■"•g adoption of common business 

reference. The computer program listing appendix includes ?y*'«i° "terfaces. The development of such business system 

the foUowine file* mterfaces at the API level requires sigmficant cooperation 

amongst the parties which is often impractical. 

USTING COMBINED.txt 83 Kbytes ere- a 4- i • j • ui . -/a. i u- u 

ated 05/29/2002 Accordingly, it is desirable to provide a framework which 

facilitates interaction amongst diverse platforms in a com- 

COPYRIGHT NOTICE munication network. Such system should facilitate sponta- 

35 neous commerce between trading partners without custom 

A portion of the disclosure of this patent document integration or prior agreement on industry wide standards, 

contains material which is subject to copyright protection. Further, such systems should encourage incremental path to 

The copyright owner has no objection to the facsimile business automation, to eliminate much of the time, cost and 

reproduction by anyone of the patent document or the patent risks of traditional systems integration, 

disclosure as it appears in the Patent and Trademark Office ^0 Overall, it is desirable to provide an electronic commerce 

patent file or records, but otherwise reserves all copyright system that replaces the closed trading partner networks 

rights whatsoever. based on proprietary standards with open markets. 

BACKGROUND OF THE INVENTION SUMMARY OF THE INVENTION 

i iJ r T 45 Tlie present invention offers an infrastructure for connect- 

1. rield ot the Invention ... .... t- * . 

mg busmesses with customers, suppuers and tradmg part- 
The present invention relates to systems and protocols ^,^^5. Under the infrastructure of the present invention, 
supporting transactions among diverse cHents coupled to a companies exchange information and services using self- 
network; and more particularly to systems and protocols defining, machine-readable documents, such as XML 
supporting commercial transactions among platforms hav- (Extensible Markup Language) based documents, that can 
ing vanant architectures. ^^g^y understood amongst the partners. Documents 

2. Description of Related Art which describe the documents to be exchanged, called 
The Internet and other communications networks provide business interface definitions BIDs herein, are posted on the 

avenues for communication among people and computer Internet, or otherwise communicated to members of the 

platforms which are being used for a wide variety of 55 network. The business interface definitions tell potential 

transactions, including commercial transactions in which trading partners the services the company offers and the 

participants buy and sell goods and services. Many efforts documents to use when communicating with such services, 

are underway to facilitate commercial transactions on the Thus, a typical business interface definition allows a cus- 

Internet. However, with many competing standards, in order tomer to place an order by submitting a purchase order, 

to execute a transaction, the parties to the transaction must 60 compliant with a document definition published in the BID 

agree in advance on the protocols to be utilized, and often of a party to receive the purchase order. A supplier is allowed 

require custom integration of the platform architectures to to check availability by downloading an inventory status 

support such transactions. Commercial processes internal to report compliant with a document definition published in the 

a particular node not compatible with agreed upon BID of a business system managing inventory data. Use of 

standards, may require substantial rework for integration 65 predefined, machine -readable business documents provides 

with other nodes. Furthermore, as a company commits to a more intuitive and flexible way to access enterprise 

one standard or the other, the company becomes locked -in to applications. 
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A node in the commerce network establishes an interface 
for transactions according to the present invention that 
comprises a machine -read able specification of an interface, 
along with a machine-readable data structure that includes 
interpretation information for the machine-readable specifi- 
cation of the interface. The machine-readable specification 
of the interface includes a definition of an input document 
and a definition of an output document, that are accepted and 
produced by transaction processes for which the node acts as 
an interface. The definitions of the input and output docu- 
ments comprise reqjective descriptions of sets of storage 
units and logical structures for sets of storage units, such as 
according to a standard XML based document. The 
machine-readable data structure that includes interpretation 
information according to various aspects of the invention 
includes data type specifications (e.g. string, array, etc.) for 
logical structures in the definitions of the input and output 
documents, content models (e.g. lists of possible values) for 
logical structures and/or data structures that map predefined 
sets of storage units for a particular logic structure to 
respective entries in a list in order to provide a semantic 
definition of logical structures (e.g. mapping codes to prod- 
uct names). 

According to other aspects of the invention, the interface 
includes a repository in memory accessible by at least one 
node in the network that stores a library of logic structures 
and interpretation information for the logic structures. The 
repository can be extended to include a library of definitions 
of input and output documents, a library of specifications of 
interfaces, and a library of specifications for participant 
interface nodes in the network. 

TTius, a participant in the transaction framework of the 
present invention executes transactions amongst nodes in a 
network that includes a plurality of nodes executing pro- 
cesses involved in the transactions. The method includes 
storing a machine -readable specification of an interface for 
a transaction, the specification includes a definition of an 
input document and a definition of an output document. The 
definition of the input and output documents comprise 
respective descriptions of sets of storage units and logical 
structures for the sets of storage units. In a preferred system, 
the definitions are expressed in a manner compliant with a 
standard XML document type definition DTD, extended by 
semantic mapping, content modeling and data typing of 
some elements. The participant in the transaction receives 
data comprising a document through a communication net- 
work. The participant parses the document according to the 
specification stored for a transaction to identify an input 
document for the transaction. After parsing the document, at 
least a portion of the input document is provided in a 
machine-readable format to a transaction process which 
produces an output. An output document is formed com- 
prising the output of the transaction process, based on the 
definition of an output document in the stored specification. 
The output document is transmitted on the communication 
network, typically back to the source of the input document, 
or elsewhere as suits the needs of a particular type of 
transaction. 

Thus the business interface definition bridges the gap 
between the documents specified for example according to 
XML and the programs which execute on the front end of the 
transaction processing services at particular nodes. Such 
front ends are implemented for example by JAVA virtual 
machines, or by other common architectures providing for 
interconnection of systems across a network. The business 
interface definition provides a technique by which a trans- 
action protocol is programmed using the business interface 
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definition document. The program for the protocol of the 
transaction is established by a detailed formal specification 
of a document type. 
The machine-readable specification of the interface of the 

5 transaction is made accessible to other platforms in the 
network. Participant platforms include resources to design 
input documents and output documents according to the 
transaction interface specified at a complementary node. 
Thus, participant nodes include resources to access the 

10 definition of an input document for the complementary 
interface and a definition of an output document for the 
complementary interface. The stored specification for the 
accessing participant node is established by including at 
least part of the definition of the output document of the 

15 complementary interface in the definition of the input docu- 
ment of the interface stored in the specification. 

The process of establishing the stored specification of an 
interface according to another aspect of the invention 
includes accessing elements of the machine-readable speci- 
fication from a repository. The repository stores a library of 
logic structures, content models, and schematic maps for 
logic structures, and definition of documents that comprise 
logic structures used to build interface description. A reposi- 
tory accessible in the network facilitates the building of 
interface descriptions which can be easily shared. Any 
differences between the input document created for a par- 
ticular process and the output document expected as a return 
by a complementary process can be easily negotiated by 
communication on the network and agreeing on common 
logic structures to express particular information. 

The machine-readable specification of an interface of a 
transaction according to one aspect of the invention includes 
a document compliant with a definition of an interface 
document that is shared amongst members of the network. 
A definition of the interface document includes logic struc- 
tures for storing an identifier of a particular transaction and 
at least one of definitions and references to definitions of 
input and output documents for the particular transaction. 

^ That is, the interface description for a particular service may 
actually encompass a definition of the input and output 
documents. Alternatively, it may include pointers to a loca- 
tion in the repository, or elsewhere in the network, of such 
definitions. 

45 According to another alternative of the invention, the 
machine -readable specification includes a business interface 
definition BID document compliant with a definition of an 
interface document that includes logical structures for stor- 
ing an identifier of the interface, and for storing at least one 

5Q of specifications and references to specifications of a set of 
one or more transactions supported by the interface. For 
each supported transaction, the document includes at least 
one of definitions and references to definitions of input and 
output documents for the particular transaction. 

55 According to another aspect of the invention, the storage 
units defined in the definitions of the input and output 
document comprise parsed data including character data 
encoding text characters, and mark-up data identifying sets 
of storage units according to the logical structures of the 

60 input and output documents. According to another aspect of 
the invention, at least one of the sets of storage units encodes 
the plurality of text characters providing a natural language 
word. This facilitates the use of the definitions of input and 
output documents by human readers and developers of such 

65 documents. 

According to another aspect of the invention, the speci- 
fication of the input and output documents includes inter- 
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prelalion information for at least one of the sets of storage 
units identified by the logical structure. The interpretation 
information in one example encodes definitions for sets of 
parsed characters. In another example, the interpretation 
information provides for content model specifications, such 5 
as requiring a specific logic structure to carry a member of 
a list of codes mapped to product descriptions in a catalog. 
In some systems, the storage units in a logic strucUire of a 
document may include sets of unparsed data, as suits the 
needs of a particular implementation. 

According to yet another aspect of the invention, the 
transaction process in a particular platform has a transaction 
processing architecture which is one of a plurality of variant 
transaction processing architectures. Thus the participant 
node includes resources for translating at least a portion of 
the input document into a format readable according to the 
variant transaction processing architecture of the transaction 
process utilizing the information. The elements of the docu- 
ment definition are translated into programming objects that 
include variables and methods according to the variant 20 
transaction processing architectures of the transaction pro- 
cess. For a participant having a JAVA virtual machine acting 
as a transaction process front end, particular fields in the 
documents are translated into JAVA objects, including the 
data as well as get and set functions associated with a JAVA 25 
object. Other transaction processing architectures support- 
able according to the present invention include processes 
compliant with an interface description language in the 
sense of Common Object Request Broker Architecture 
CORBA, Component Object Model COM,On-Line Trans- 30 
action Processing OLTP, and Electronic Data Interchange 
EDI. 

According to other aspects of the invention, a repository 
is provided that stores document types for use in the plurality 
of transactions. The machine-readable specification for a 35 
particular transaction defines at least one of the input and 
output documents by reference to a document type in the 
repository. According to another aspect, the document type 
included in the repository include a document type for 
identifying participants in the network. Such document type 40 
providing structures for identifying a participant, specifying 
the services supported by the participant, and specifying the 
input and output documents for each of such services. 

In addition to the methods described above, the present 
invention provides an apparatus for managing transactions 45 
among nodes that includes a network interface, memory for 
storing data and programs of instructions including a 
machine-readable specification of an interface for a trans- 
action as described above, and a data processor that is 
coupled with the memory and the network interface. The 50 
programs of instructions stored in the apparaUis include 
logic to execute the processes described above for a partici- 
pant in the transactions. 

The present invention further provides an apparatus for 
establishing participant interfaces for transactions executed 55 
on a system that include a network interface and a data 
processing resources that execute transaction processes 
according to a transaction processing architecture. The appa- 
ratus includes programs of instructions that are executable 
by the system and stored on a medium accessible by the 60 
system that provide tools to build a definition of a participant 
interface for a participant in a particular transaction. The 
definition of a participant interface includes a definition of 
an input document and a definition of an output document. 
The definitions of the input and output documents comprise 65 
respective machine-readable descriptions of sets of storage 
units in logical structures for the sets of storage units, which 
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may be compliant in one aspect of the invention with XML 
document type definitions. 

The apparatus for establishing participant interfaces 
according to this aspect of the invention also includes 
programs of instructions stored on a medium accessible by 
the data processing system and responsive to the definitions 
of input and output documents to compile data structures 
corresponding to the sets of storage units and logical struc- 
tures of the input and output documents that are compliant 
with the transaction processing architecture, to compile 
instructions executable by the system to translate the input 
document to the corresponding data stmctures, and to com- 
pile instructions executable by the system to translate output 
of the transaction processes into sets of storage units and 
logical structures of the output document. 

The tools to build a definition of a participant interface in 
a preferred system include instructions executable by the 
system to access elements of the definition from comple- 
mentary nodes and/or from a repository that stores a library 
of logical structures and interpretation infonnation for logi- 
cal structures used to build interface descriptions. According 
to various aspects of the invention, the repository includes 
not only a library of logical structures but definitions of 
documents that comprise logical structiu-es, and formats for 
specifying participant interfaces. According to this aspect of 
the invention, tools are provided for building specifications 
of business interfaces according to the techniques described 
above in connection with the description of the participant 
nodes. The tools for building interfaces and the tools for 
compiling the interfaces into resources needed for commu- 
nication with transaction processing architectures according 
to this aspect of the invention, arc implemented in partici- 
pant nodes in the preferred system, and utilized for the 
development and optimization of the interface descriptions 
as use of the network grows based on interface descriptions 
that define input and output documents. 

Accordingly, another aspect of the invention provides an 
apparahis that includes memory and a data processor that 
executes instructions stored in the memory that include tools 
to build a definition of a participant interface and a compiler 
performing the functions described above. 

According to yet another aspect of the invention, the use 
of the participant interface descriptions enables the opera- 
tion of a market maker node. At such a node, a method for 
managing transactions is provided that comprises storing 
machine -readable specifications of a plurality of participant 
interfaces which identify transactions supported by the 
interfaces, and the respective input and output documents of 
such transactions. As described above, the definitions of the 
input and output documents comprise respective descrip- 
tions of sets of storage units and logical structures for the 
sets of storage units, such as according to the XML standard. 
In addition, the definitions of the transactions and the 
definitions of the participant interfaces all comprise docu- 
ments specified according to a technique compliant with 
XML or other standardized document expression language. 
At such market maker node, data comprising a document is 
received over a communication network. The document is 
parsed according to the specifications to identify an input 
document in one or more transactions which accept the 
identified input document. At least a portion of the input 
document is provided in a machine-readable formal to a 
transaction process associated with the one or more identi- 
fied transactions. The step of providing at least a portion of 
the input document to a transaction process includes execut- 
ing a routing process according to a processing architecture 
at the market maker node. The routing process in one aspect 
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of the invention is executed according to a particular pro- For complete business integration, the present invention 

cessing architecture, and at least a portion of the incoming provides a repository of standardized logical structures, like 

document is translated into the format of the processing XML elements, attributes or meta data, establishing a 

architecture of the routing process. The translating accord- semantic language for particular commerce communities, a 

ing to the preferred aspect includes producing programming 5 means for mapping between different meta data 

objects that include variables and methods according to the descriptions, and a server for processing the documents and 

processing architecture of the routing process. invoking appropriate applications and services. The basic 

According to another aspect of the invention, the market building blocks of a network according to the present 
maker node also supports the repository structure. Thus, a invention include the business interface definitions which 
process is included at the market maker node for allowing lo tell potential trading partners what online services a corn- 
access by participants in the network to a repository stored pany offers and which documents to use to invoke the 
at the market maker node. As described above, the reposi- services; and servers which provide the bridge to bind 
tory includes definitions of logic structures, interpretation together the set of internal and external business services to 
information, and document definitions for use by the par- create a trading community. The server operates to parse the 
ticipant nodes to build transaction interface documents and 15 incoming documents and invoke the appropriate services, 
includes instances of business interface definitions that Also the server according to the present invention handles 
identify the participants, and the transactions executed by translation tasks from the format of the documents being 
the respective participants. received and transmitted, to and from the formats of the 

The routing process includes according to various alter- respective host systems. Thus, trading partners need only 

natives the translating of the input document into the variant structure, content and sequencing of the busi- 

processing architecture of the processes to which the docu- documents exchanged, and not on the details of apph- 

ment is to be routed, or routing the input document in its ""^f? programmer mterfaces How a docurnent is processed 

original document format across the network to a remote actions which result from receipt of a documentare 

processing node, or to combinations of such processes. In ^^^^^y busmesses providmg the services. This 

ahernatives, the routing process may also include techniques ^5 elevates integration from the system level to the business 

for transforming an input document defined according to one 1^^^^, ^""^^^^^ ^'^^"'^f ^o present a clean and stable 

input document definition into a different document defined P^^"^^^ ^^^^^^ ^^^^"^^^ 

according to a different document specification for a process technology miple mentation, organization or processes, 

which has registered to watch for the input document. The whole process of building business mterface defim- 

Also, the market maker node is provided according to the and enabling servers to manage commerce according 

present invention as apparatus that includes a network J? ^^^^ descriptions is facilitated by a common business 

interface, memory storing data and programs of instructions ^'^^^^^ repository of information models for genenc 

including the specifications of the participant interfaces, and business concepts includmg busmess descnption prmiitives 

a data processor. The logic is provided with the data pro- „ like companies services and products, business forms hke 

cessor in the form of programs of instructions or otherwise purchase orders and invoices, and standard 

to perform the market maker process as discussed above. measurements, includmg time and date, location and clas- 

, , . . .1 r J • sification of goods. 

Accordingly, the present invention provides a toundation „ , 

for electronic commerce based on the sharing of specifica- Other Ejects of the present invention can be seen upon 

lions of input and output documents. Documents provide an 40 '^'7. „ ^'^^ descnption, and the claims 

intuitive and flexible way to access business services, much wnicti tollow. 

simpler to implement than programming APIs. It is much BRIEF DESCRIFTION OF THE FIGURES 
easier to interconnect companies in terms of documents that 

are exchanged, on which such companies already largely FIG. 1 is a simplified diagram of an electronic commerce 

agree, than in terms of business system interfaces which 45 network including business interface definitions BIDs 

invariably differ. In addition, such documents are specified according to the present invention. 

in a human readable format in the preferred embodiment. FIG. 2 is a simplified diagram of a business interface 

According to the present invention the business interfaces definition document according to the present invention, 

are specified in documents, such as XML documents that are y\G. 3 is a conceptual block diagram of a server for a 

readily interpretablc by humans as well as by computers, 50 participant node in the network of the present invention. 

Utilization of the document based transaction architecture piQ. 4 is a flow chart illustrating the processing of a 

of the present invention involves the use of a parser which received document at a participant node according to the 

operates in basically the same way for any source of present invention. 

documents, eliminating much of the need for custom pro- 5 J3 ^ ^^^^^ ^. ^ transaction 

grams to extract and integrate mformation from each par- 55 ^^^^^ ^^^^ y^^^ ^ased system. 

ticipant in the network. Thus, integrating enterprise mfor- ^T^.r* ,j. r t. a r 

„ r. P ^. . . r * • EIG. 6 IS a conceptual diagram of the now of a parse 

mation from accounting, purchasing, manufacturing, function r & r 
shipping and other functions can be accomplished by first 

converting each source to a document having an architecture Fl^. 7 is a simplified diagram of the resources at a server 

according to the present invention, and then processing the 60 for building a business interface definition accordmg to 

parsed data stream. Each node in the system that participates present invention. 

in the market only needs to know about the format of its FIG. 8 is a simpUfied diagram of a repository according 
internal systems, as well as the format of the documents to the present invention for use for building business inter- 
being specified for interchange according to the transaction. face definitions. 

Thus, there is no need to be able to produce the native format 65 FIG. 9 is a flow chart illustrating the processes of building 

of every other node which might want to participate in the a business interface definition according to the present 

electronic commerce network. invention. 
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FIG. 10 provides a heuristic view of a repository accord- 
ing to the present invention. 

FIG. 11 is a simplified diagram of the resources at a server 
providing the market maker function for the network of the 
present invention based on business interface definitions. 5 

FIG. 12 is a flow chart for the market maker node 
processing of a received document. 

FIG. 13 is a flow chart iUustrating the process of regis- 
tering participants at a market maker node according to the 
present invention. 

FIG. 14 is a flow chart illustrating the process of provid- 
ing service specifications at a market maker node according 
to the process of FIG. 9. 

FIG. 15 is a diagram illustrating the sequence of operation 15 
at a participant or market maker node according to the 
present invention. 

FIG. 16 is a conceptual diagram of the elements of a 
commercial network based on BIDs, according to the 
present invention. 20 

DETAILED DESCRIPTION 

A detailed description of the present invention is provided 
with respect to the figures, in which FIG, 1 illustrates a 
network of market participants and market makers based on 
the use of business interface definitions, and supporting the 
trading of input and output documents specified according to 
such interface descriptions. The network includes a plurality 
of nodes 11-18 which are intercormected through a com- 
munication network such as the Internet 19, or other tele- 
communications or data communications network. Each of 
the nodes 11-19 consists of a computer, such as a portable 
computer, a desktop personal computer, a workstation, a 
network of systems, or other data processing resources. The 
nodes include memory for storing the business interface 
definition, processors that execute transaction processes 
supporting commercial transactions with other nodes in the 
network, and computer programs which are executed by the 
processors in support of such services. In addition each of 
the nodes includes a network interface for providing for 
communication across the Internet 19, or the other commu- 
nication network. 

In the environment of FIG. 1, nodes 11, 12, 13, 14, 16 and 
18 are designated market participants. Market participants 45 
include resources for consumers or suppliers of goods or 
services to be traded according to commercial transactions 
established according to the present invention. 

In this example, nodes 15 and 17 are market maker nodes. 
The market maker nodes include resources for registering 50 
business interface definitions, called a BID registry. Partici- 
pants are able to send documents to a market maker node, at 
which the document is identified and routed to an appropri- 
ate participant which has registered to receive such docu- 
ments as input. The market maker also facilitates the com- 55 
mercial network by maintaining a repository of standard 
forms making up a common business hbrary for use in 
building business interface definitions. 

In this example, the market participant 18 is connected 
directly to the market maker 17, rather than through the 60 
Internet 19. This connection directly to the market maker 
illustrates that the configuration of the networks supporting 
commercial transactions can be very diverse, incorporating 
public networks such as the Internet 19, and private con- 
nections such as a local area network or a Poinl-to-Point 65 
connection as illustrated between nodes 17 and 18. Actual 
communication networks are quite diverse and suitable for 
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use to establish commercial transaction networks according 
to the present invention. 

FIG. 2 is a heuristic diagram of nested structures in a 
business interface definition BID which is established for 
market participants in the network according to the present 
invention. The business interface definition illustrated in 
FIG. 2 is a data structure that consists of logic structures and 
storage units arranged according to a formal definition of a 
document structure, such as a XML document type defini- 
tion DTD. The structure of FIG. 2 includes a first logic 
structure 200 for identifying a party. Associated with the 
logic structure 200 are nested logic structures for carrying 
the name 201, the physical address 202, the network address 
or location 203, and a set of transactions for a service 204. 
For each transaction in the service set, an interface definition 
is provided, including the transaction BID 205, the transac- 
tion BID 206, and the transaction BID 207. Within each 
transaction BID, such as transaction BID 205, logical struc- 
tures are provided for including a name 208, a location 
on-the network at which the service is performed 209, the 
operations perfonned by the service 210, and a set of input 
documents indicated by the tag 211. Also, the service BID 
205 includes a set of output documents indicated by the tag 
212. The set of input documents 211 includes a business 
interface definition for each input document for which the 
services are designed to respond, including input document 
business interface definitions 213, 214, and 215. Each busi- 
ness interface definition for an input document includes a 
name 216, a location on the network at which a description 
of the document can be found 217, and the modules to be 
carried in the document as indicated by the field 218, In a 
similar manner, the output document set 212 includes inter- 
face definitions for output documents including the output 
document BID 219, output document BID 220, and output 
document BID 221. For each output document BID, a name 
222, a location on the network or elsewhere 223, and the 
modules of the document 224 are specified. The business 
interface definition for the participant as illustrated in FIG. 
2 includes actual definitions of a logic structures to be 
utilized for the input and output documents of the respective 
services, or pointers or other references to locations at which 
these definitions can be found. 

In the prefened system, the document of FIG. 2 is 
specified in an XML document type definition DTD, 
although other document definition architectures could be 
used, and includes interpretation inforaiation for the logical 
stmctures used in interpretation of instances of the docu- 
ments. In addition, each of the transaction BIDs, input 
document BIDs and output document BIDs are specified 
according to an XML document type definitions. The XML 
type document is an example of a system based on parsed 
data that includes mark-up data and character data. Mark-up 
data identifies logical structures within the document and 
sets of character data identify the content of the logical 
structures. In addition, unparsed data can be carried in the 
document for a variety of purposes. See for example the 
specification of the Extensible Mark-up Language AML 1.0 
REC-XML-19980210 published by the WC3 XML Working 
Group at WWW.W3.ORG/rR/1998/REC-XML-19980210. 

Thus in an exemplary system, participant nodes in the 
network establish virtual enterprises by interconnecting 
business systems and services with XML encoded docu- 
ments that businesses accept and generate. For example, the 
business interface definition of a particular service estab- 
lishes that if a document matching the BID of a request for 
a catalog entry is received, then a document matching a BID 
of a catalog entry will be returned. Also, if a document 
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matching the BID of a purchase order is received, and it is includes data typing, such as for example the element 
acceptable to the receiving terminal, a document matching <H3> Internet Address</H3> including the content form 
the BID of an invoice will be returned. The nodes in the "url" and expressed in the data type "string." Yet other 
network process the XML documents before they enter the interpretation information includes mapping of codes to 
local business system, which is established according to the 5 elements of a list, such as for example the element 
variant transaction processing architecture of any given <H3>State</H3> including the code mapping for states in 
system in the network. Thus, the system unpacks sets of the file "COUNTRYUS.SUBENTITY." 
related documents, such as MIMEnencoded sets of XML The service description referred to by the market partici- 
documents, parses them to create a stream of "mark-up pant DTD defines the documents that the service accepts and 
messages". The messages are routed to the appropriate lo generates upon competition of the service, A basic service 
applications and services using for example an event listener description is specified below as a XML document trans- 
model like that described below. acl.dtd. 

The documents exchanged between business services are Transact.dtd models a transaction description, such as an 

encoded using an XML language built from a repository of invoice, or a description of an exchange of value. This 
building blocks (a common business language) from which ^5 document type supports many uses, so the transaction 

more complex document definitions may be created. The description element has an attribute that allows user to 

repository stores modules of interpretation information that distinguish among invoices, performance, offers to sell, 

are focused on the fiinctions and information common to requests for quotes and so on. The exchange may occur 

business domains, including business description primitives among more than two parties, but only two are called out, 

like companies, services and products; business forms like 20 offeror and the counter party, each of whom is repre- 

catalogs, purchase orders and invoices; standard sented by a pointer to a document conforming to the market 

measurements, like time, date, location; classification codes participant DTD outlined above. The counter party pointer is 

and the like providing interpretation information for logical optional, to accommodate offers to sell. The exchange 

structures in the XML documents. description is described in the module tranprim.mod listed 

The business interface definition is a higher level docu- below, and includes pricing and subtotals. Following the 
ment that acts as a schema used for designing interfaces that exchange description, charges applying to the transaction as 
trade documents according to the present invention. Thus the a whole may be provided, and a total charge must be 
business interface definition bridges the gap between the supplied. Thus, the transaction description schema docu- 
documents specified according to XML and the programs ment transact.dtd for this example is set forth below: 
which execute on the front end of the transaction processing 
services at particular nodes. Such front ends are imple- 
mented by JAVA virtual machines, or by other common — — — 
architectures providing for interconnection of systems 1" ^'"'^'''fJ^'i^^Q^Sf' i'^"'' i 

■ . ^ , i ■ ■ — Copynght 1998 Vfco Systems, Inc. — > 

across a network. Thus, the business mterface definition 

provides a technique by which a transaction protocol is <!E1^MENT transaction.dcscriptioQ (mcta?, issucr.pomicr, 

programmed using the business interface definition docu- countciparty.pointer?, exhange.dcscrption+, gencral.charges?, 

ment. The program for the protocol of the transaction is ,a'^'x'^P^ r ^ • . 

* ui- u J u J 4 '1 J i- 1 -c c J * <!ArTLISTtransaction.dc5cription 

established by a detailed formal specification of a document transaction.type (invoice | pro. forma | oflfer.to.sell t order 

" rcqucsLfor-quotc | request. for.bid 



type. 

40 

An example business interface definition BID based on a 



market participant document which conforms to an XML 

format is provided below. The market participant DTD %conimon.attrib; 
groups business information about market participants, asso- %altrcp.attrib; 

dating contact and address information with a description of ^ %tti.attrib; 
services and financial information. This business informa- 



requesLfor.proposal | response. to. request. fiDr.quote 
re&pon&e.to.request.for.bid 
response .to .request, fo r.proposal) "invoice' ' 



tion is composed of names, codes, addresses, a dedicated 

taxonomic mechanism for describing business organization, Representative market participant, and service DTDs, 

and a pointer to tenns of business. In addition, the services created according to the definitions above, are set forth as 

identified by the market participant DTD will specify the LISTING 3, in the file named LISTING COMBINED.txt in 

input and output documents which that participant is the accompanying computer program listing appendix, 

expected respond to and produce. Thus, documents which One instance of a document produced according to the 

define schema using an exemplary common business Ian- transact.dtd is set forth as LISTING 4, in the file named 

guage for a market participant DTD, a service DTD, and a LISTING COMBINED.txt in the accompanying computer 

transaction document DTD specified in XML with explana- program listing appendix. 

tory comments are set forth as LISTING 1, in the file named Accordingly, the present invention provides a technique 

LISTING COMBINED.txt in the accompanying computer by which a market participant is able to identify itself, and 

program listing appendix. identify the types of input documents and the types of output 

The service DTD schema may be extended with a service documents with which it is willing to transact business. The 
type clement in a common business language repository, an go particular manner in which the content carried in such 

example of which is set forth as LISTING 2, in the file documents is processed by the other parties to the 

named LISTING COMBINED.txt in the accompanying transaction, or by the local party, is not involved in eslab- 

computer program listing appendix. lishing a business relationship nor carrying out transactions. 

The service type element above illustrates interpretation FIG. 3 provides a simplified view of a participant node in 
information carried by a business interface definition, in this 65 the network according to the present invention. The node 

example a content form allowing identification of any one of illustrated in FIG. 3 includes a network interface 300 which 

a list of valid service types. Other interpretation information is coupled to a communication network on port 301. The 
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network interface is coupled to a document parser 301. The outlined above include a schematic mapping for logic ele- 

parser 301 supplies the logical structures from an incoming ments in the documents, and include mark-up language 

document to a translator module 302, which provides for based on natural language. The natural language mark-up, 

translating the incoming document into a fonn usable by the and other natural language attributes of XML facUitate the 

host transaction system, and vice versa translating the output 5 use of XML type mark-up languages for the specification of 

of host processes into the format of a document which business interface definitions, service descriptions, and the 

matches the output document form in the business interface descriptions of input and output documents, 

definition for transmission to a destmation. The parser 301 _ . . * , -^^^ • jj- • 

and translator 302 are responsive to the business interface participant module 303 m addition to storing the 

definition stored in the participant module 303. busmess mtcrface definition mcludes a compiler which is 

The output data structures fi-om the translator 302 are ^° used to compUe objects or other data structures to be used by 

supplied to a transaction process front end 304 along with transaction process front end 304 which corresponds to 

events signaled by the parser 301, The front end 304 in one io^ca\ structures in the incoming documents, and to 

embodiment consists of a JAVA virtual machine or other compile the translator 302. Thus, as the business interface 

similar interface adapted for communication amongst definition is modified or updated by the participant as the 

diverse nodes in a network. The transaction processing front transactions with which the participant is involved change, 

end 304 responds to the events indicated by the parser 301 translator 302 and parser 301 are automatically kept up 

and the translator 302 to route the incoming data to appro- ^ 

priate functions in the enterprise systems and networks to In a preferred system, the set of JAVA events is created by 

which the participant is coupled. Thus, the transaction a compiler which corresponds to the grove model of SGML, 

process front end 304 in the example of FIG. 3 is coupled to ^° mainly the standard Element Structure Information Set 

commercial functions 305, database functions 306, other augmented by the "property set" for each element. Interaa- 

enterprise functions such as accounting and billing 307, and tional Standard ISO/IEC 10179:1996 (E), Information 

to the specific event listeners and processors 308 which are Technology — Processing Languages — Document Style 

designed to respond to the events indicated by the parser. Semantics and Specification Language (DSSSL). Turning 

The parser 301 takes a purchase order like thai in the the XML document into a set of events for the world to 

example above, or other document, specified according to process contrasts with the normal model of parsing in which 

the business interface definition and creates a set of events ^® parser output is maintained as an internal data structure, 

that are recognized by the local transaction processing By translating the elements of the XML document into JAVA 

architecture, such as a set of JAVA events for a JAVA virtual events or other programming structures that are suitable for 

machine. use by the transaction processing front end of the respective 

The parser of the present invention is uncoupled from the ^^^^ enables rich functionality at nodes utilizing the docu- 

programs that hsten for events based on the received docu- tnents being traded. 

ments. Various pieces of mark-up in a received document or Thus, the transaction process front end 304 is able to 

a complete document meeting certain specifications serve as 35 operate in a publish and subscribe architecture that enables 

instructions for listening functions to start processing. Thus the addition of new listener programs without the knowledge 

listening programs carry out the business logic associated of or impact on other listening programs in the system. Each 

with the document information. For example, a program listener, 305, 306, 307, 308 in FIG. 3, maintains a queue in 

associated with an address element may be code that vali- which the front end 304 directs events. This enables multiple 

dates the postal code by checking the database. These ^ listeners to handle events in parallel at their own pace, 

listeners subscribe to events by registering with a document Furthermore, according to the present invention the appli- 

router, which directs the relevant events to aU subscribers cations that the listeners run need not be native XML 

who are interested in them. functions, or native functions which match the format of the 

For example, the purchase order specified above may be incoming document. Rather, these listeners may be JAVA 

monitored by programs listening for events generated by the 45 functions, if the transaction process front end 304 is a JAVA 

parser, which would connect the document or its contents to interface, or may be functions which run according to a 

an order entry program. Receipt of product descriptions unique transaction processing architecture. In these cases, 

within the purchase order, might invoke a program to check the objects would be transformed into the format required by 

inventory. Receipt of address information within the pur- the receiving application. When the application of the lis- 

chase order, would then invoke a program to check avail- 59 tener finishes, its output is then transformed back into the 

ability of services for delivery. Buyer information fields in format of a document as specified by the business interface 

the document, could invoke processes to check order history definition in the module 303. Thus, the translator 302 is 

for credit worthiness or to offer a promotion or similar coupled to the network interface 300 directly for supplying 

processing based on knowing the identity of the consumer. the composed documents as outputs. 

Complex listeners can be created as configurations of 55 The listeners coupled to the transaction processing front 

primitive ones. For example, a purchase order listener may end may include listeners for input documents, listeners for 

contain and invoke the list listeners set out in the previous specific elements of the input documents, and listeners for 

paragraph, or the list members may be invoked on their own. attributes stored in particular elements of the input docu- 

Note that the applications that the listeners run are unlikely ment. This enables diverse and flexible implementations of 

to be native XML processes or native JAVA processes. In 60 transaction processes at the participant nodes for filtering 

these cases, the objects would be transformed into the format and responding to incoming documents, 

required by the receiving trans application. When the appli- FIG. 4 illustrates a process of receiving and processing an 

cation finishes processing, its output is then transformed incoming document for the system of FIG. 3. Thus, the 

back to the XML format for communication to other nodes process begins by receiving a document at the network 

in the network. 65 interface (step 400). The parser identifies the document type 

It can be seen that the market participant document type (401) in response to the business interface definition. Using 

description, and the transaction document type description the business interface definition, which stores a DTD for the 
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document in the XML format, the document is parsed (step 
402), Next, the elements and attributes of the document are 
translated into the format of the host (step 403). In this 
example, the XML logic structures are translated into JAVA 
objects which carry the data of the XML element as well as 5 
methods associated with the data such as get and set func- 
tions. Next, the host objects are transfened to the host 
transaction processing front end (step 404). These objects 
are routed to processes in response to the events indicated by 
the parser and the translator. The processes which receive 
the elements of the document are executed and produce an 
output (step 405). The output is translated to the format of 
an output document as defined by the business interface 
definition (step 406), In this example, the translation pro- 
ceeds from the form of a JAVA object to that of an XML 
document. Finally, the output docimaent is transmitted to its 
destination through the network interface (step 407). 

FIG. 5 is a more detailed diagram of the event generator/ 
event listener mechanism for the system of FIG. 3. In 
general the approach illustrated in FIG. 5 is a refinement of 20 
the JAVA JDK 1.1 event model. In this model, three kinds of 
objects arc considered. A first kind of object is an event 
object which contains information about the occurrence of 
an event. There may be any number of kinds of event 
objects, corresponding to all the different kinds of events 25 
which can occur. A second kind of object is an Event 
generator, which monitors activity and generates event 
objects when something happens. Third, event listeners, 
listen for event objects generated by event generators. Event 
listeners generally listen to specific event generators, such as 30 
for mouse clicks on a particular window. Event listeners call 
an "ADD event listener" method on the event generator. 
This model can be adapted to the enviromnent of FIG. 3 in 
which the objects are generated in response to parsing and 
walking a graph of objects, such as represented by an XML 35 
document. 

The system illustrated in FIG. 5 includes a generic XML 
parser 500. Such parser can be implemented using a standard 
call back model When a parsing event occurs, the parser 
calls a particular method in an application object, passing in 40 
the appropriate information in the parameters. Thus a single 
application 501 resides with the parser. The application 
packages the information provided by the parser in an XML 
event object and sends it to as many event listeners as have 
identified themselves, as indicated by the block 502. The set 45 
of events 502 is completely parser independent. The events 
502 can be supplied to any number of listeners and any 
number of threads on any number of machines. The events 
are based on the element structure information set ESIS in 
one alternative. Thus, they consist of a list of the important 50 
aspects of a document structure, such as the starts and ends 
of elements, or of the recognition of an attribute. XML (and 
SGML) parsers generally use the ESIS structure as a default 
set of information for a parser to return to its application. 

A specialized ESIS listener 503 is coupled to the set of 55 
events 502. This listener 503 implements the ESIS listener 
API, and listens for all XML events from one or more 
generators. An element event generator 504 is a specialized 
ESIS hstener which is also an XML event generator. Its 
listeners are objects only interested in events for particular 60 
types of elements. For example in an HTML environment, 
the listener may only be interested in ordered lists, that is 
only the part of the document between the <0L> and 
</OL>tags. For another example, a listener may listen for 
"party.name" elements, or for "service. name" elements 65 
according to the common business language, from the 
example documents above, process the events to ensure that 
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the elements carry data that matches the schematic mapping 
for the element, and react according to the process needed at 
the receiving node. 

This allows the system to have small objects that listen for 
particular parts of the document, such as one which only 
adds up prices. Since listeners can both add and remove 
themselves from a generator, there can be a Ustener which 
only listens to for example the <HEAD> part of an HTML 
document. Because of this and because of the highly recur- 
sive nature of XML documents, it is possible to write highly 
targeted code, and to write concurrent listeners. For 
example, an <0L> listener can set up an <LI> listener 
completely separate from the manner in which the <UL> 
(unordered list) listener sets up its <LI> listener. 
Alternatively, it can create a listener which generates a 
graphic user interface and another which searches a database 
using the same input. Thus, the document is treated as a 
program executed by the listeners, as opposed to the finished 
data structure which the application examines one piece at a 
time. If an application is written this way, it is not necessary 
to have the entire document in memory to execute an 
application. 

The next listener coupled to the set of events 502 is an 
attribute filter 505. The attribute filter 505 like the element 
filler 504 is an attribute event generator according to the 
ESIS listener model. The listener for an attribute filter 
specifies the attributes it is interested in, and receives events 
for any element having that attribute specified. So for 
example, a font manager might receive events only for 
elements having a font attribute, such as the <P FONTa 
"Times Roman"/P>. 

The element event generator 504 supplies such element 
objects to specialize the element listeners 504A. 

The attribute event generator 505 supplies the attribute 
event objects to attribute listeners 505A. Similarly, the 
attribute objects are supplied to a "architecture" in the sense 
of an SGML/XML transformation from one document type 
to another using attributes. Thus the architecture of 505B 
allows a particular attribute with a particular name to be 
distinguished. Only elements with that attribute defined 
become part of the output document, and the name of the 
element in the output document is the value of the attribute 
in the input document. For example, if the architecture 505B 
is HTML, the string: 

<PURCHASES HTMLo«OL"><ITEM 

HTML-"U"><NAME 

HTML-"B">STUFF</NAME><PRICE 

HTML-"B">123</PRICE></ITEM></PURCHASES> 
translates into: 

<OL><LI><B>STUFF</B><B>123</B></LI></OL> 
which is correct HTML. 

The next module which is coupled to the set of events 502 
is a tree builder 506. The tree builder takes a stream of XML 
events and generates a tree representation of the underlying 
document. One preferred version of the tree builder 506 
generates a document object model DOM object 507, 
according to the specification of the W3C (See, http:// 
www.w3.org/TR/1998/WD-DOM-19980720/ 
introduction, html). However listeners in event streams can 
be used to handle most requirements, a tree version is useful 
for supporting queries around a document, reordering of 
nodes, creation of new documents, and supporting a data 
structure in memory from which the same event stream can 
be generated multiple times, for example like parsing the 
document many limes. A specialized builder 508 can be 
coupled to the tree builder 506 in order to build special 
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subtrees for parts of the document as suits a particular The organization of the processing module illustrated in 

implementation. FIGS. 5 and 6 is representative of one embodiment of the 

In addition to responses to incoming documents, other parser and transaction process front end for the system of 

sources of XML events 502 can be provided. Thus, an event piG. 3. As can be seen, a very flexible interface is provided 

stream 510 is generated by walking over a tree of DOM 5 by which diverse transaction processes can be executed in 

objects and regenerating the original event stream created response to the incoming XML documents, or other struc 

when the document was bemg parsed. This allows the tu^ed document formats. 

system to present the appearance that the document is being pj^ 7 ^j^^^^^^^^ ^ ^-^^^ ^^^^ 3^ ^^^p^ 

^''^e Wea of alTobject which walks a tree and generates a , , ^51 ^15^"^^'' ' ^^^^^^^^^f ^'^''^"^ ^'^"^^^ "^^f 

stream of events can be generalize beyond the tree of DOM l^- ^^^^^"^ ^ ^^^f^^ ^ network mterfaoe 

objects, to any tree of objects which can be queried. Thus, ^ document parser 702, and a document translator 703. 

aJAVAwalker512maybeanappUcationwhichwalksatree translator 703 supplies its output to a transaction 

of JAVA bean components 513. The walker walks over all processmg front end 704, which in turn is coupled to 

the pubUcly accessible fields and methods. The walker keeps listening functions such as commercial functions 705, a 

track of the objects it has already visited to ensure that it 15 database 706, enterprise functions 707, and other generic 

doesn't go into an endless cycle. JAVA events 514 are the listeners and processors 708. As illustrated in FIG. 7, the 

type of events generated by the JAVA walker 512. This business interface definition builder 700 includes a user 

currently includes most of the kinds of information one can interface, a comnaon business library CBL repository, a 

derive from an object. This is the JAVA equivalent of ESIS process for reading complementary business interface 

and allows the same programming approach applied to XML 20 definitions, and a compiler. The user interface is used to 

to be applied to JAVA objects generally, although particu- assist an enterprise in the building of a business interface 

larly to JAVA beans. definition relying on the common business library 

The JAVA to XMLevent generator 515 constitutes a JAVA repository, and the ability to read complementary business 

listener and a JAVA event generator. It receives the stream of interface definitions. Thus, the input document of a comple- 

events 514 from the JAVA walker 512 and translates selected 25 mentary business interface definition can be specified as the 

ones to present a JAVA object as an XML document. In the output document of a particular transaction, and the output 

one preferred embodiment, the event generator 515 exploits document of the complementary business interface defini- 

the JAVA beans API. Each object seen becomes an element, tion can be specified as the input to such transaction process, 

with the element name the same as the class name. Within In a similar manner a transaction business interface defini- 

that element, each embedded method also becomes an 30 tion can be composed using components selected from the 

element whose content is the value returned by invoking the CBL repository. The use of the CBL repository encourages 

method. If it is an object or an array of objects, then these the use of standardized document formats, such as the 

are walked in turn. example schema (bidl) documents above, logical structures 

no. 6 outlines a particular application built on the and interpretation information in the building of business 

framework of FIG. 5. This application lakes in an XML 35 interface definitions which can be readily adopted by other 

document 600 and applies it to a parser/generator 601. ESIS people in the network. 

events 602 are generated and supplied to an attribute gen- The business interface definition builder module 700 also 
erator 603 and tree builder 604. The attribute generator includes a compiler which is used for generating the trans- 
corresponds to the generator 505 of FIG. 5. It supplies the lator 703, the objects to be produced by the translator 
events to the "architecture" 505B for translating the XML 40 according to the host transaction processing architecture, 
input to an HTML output for example. These events are and to manage the parsing function 702. 
processed in parallel as indicated by block 605 and pro- FIG. 8 is a heuristic diagram showing logical structures 
cessed by listeners. The output of the listeners are supplied stored in the repository in the business interface definition 
to a document writer 506 and then translated back to an builder 700. Thus, the repository storage representative 
XML format for output. Thus for example this application 45 party business interface definitions 800, including for 
illustrated in FIG. 6 takes an XML document and outputs an example a consumer BID 801, a catalog house BID 802, a 
HTML document containing a form. The form is then sent warehouse BID 803, and an auction house BID 804. Thus, 
to a browser, and the result is converted back to XML. For a new participant in an online market may select as a basic 
this exercise, the architecture concept provides the mapping interface description one of the standardized BIDs which 
from XML to HTML. The three architectures included in 50 best matches its business. In addition, the repository will 
FIG. 6 include one for providing the structure of the HTML store a set of service business interface definitions 805. For 
document, such as tables and lists, a second specifying text example, an order entry BID 806, an order tracking BID 
to be displayed, such as labels for input fields on the browser 807, an order fulfilhnent BID 808, and a catalog service BID 
document, and the third describes the input fields them- 809 could be stored. As a new participant in the market 
selves. The elements of the XML document required to 55 builds a business interface definition, it may select the 
maintain the XML documents structure become invisible business interface definitions of standardized services stored 
fields in the HTML form. This is useful for use in recon- in the repository. 

struction of the XML document from the information the In addition to the party and service BIDs, input and output 

client will put into the HTTP post message that is sent back document BIDs are stored in the repository as indicated by 

to the server. Each architecture takes the input document and 60 the field 810. Thus, a purchase order BID 811, an invoice 

transforms it into an architecture based on a subset of BID 812, a request for quote BID 813, a product availability 

HTML. Listeners listening for these events, output events report BID 814, and an order status BID 815 might be stored 

for the HTML document, which then go to a document in the repository. 

writer object. The document writer object listens to XML The repository, in addition to the business interface defi- 

events and turns them back into an XML document. The 65 nitions which in a preferred system are specified as docu- 

document writer object is a listener to all the element ment type definitions according to XML, stores inlerpreta- 

generators listening to the architectures in this example. tion information in the form of semantic maps as indicated 
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by the field 816. Thus, semantic maps which are used for example, purchase orders typically contain the names and 

specifying weights 817, currencies 818, sizes 819, product addresses of the buyer and seller, a set of product descrip- 

ideotifiers 820, and product features 821 in this example tions, and associated terms and conditions such as price and 

might be stored in the reposUory. Birther, the interpreUtioD delivery dates. In Electronic Data Interchange EDI for 

Scrr^e:^^^^^^^^^ ' --Pl^ - ^ — nly used 

In addition, logical structures used in the composing of " _ ' purchase orders, 

business interface definitions could be stored in the reposi- , ^« repository encourages the development of XML 

tory as indicated by block 822. Thus, forms for providing <Joc<"°ent models from reusable semantic components that 

address information 823, forms for providing pricing infor- lo ^ ""^^ ^"""^ documents 

mation 824, and forms for providing terms of contractual "° ^ understood from their common message elements, 

relationships could be provided 825. As the network even though they may appear quite different. This is the role 

expands, the CBL repository wUl also expand and standard- ^°'°°«"' business Library repository, 

ize tending to make the addition of new participants, and the . .^f library repository consists of 
modification of business interface definitions easier. 15 ^^^ormmon models for generic busmess concepts including; 

FIG. 9 illustrates the process of building a business business description primitives like companies, services, 

interface definition using the system of FIG. 7. The process , and products; 

begins by displaying a BID builder graphical interface to the ^^^^ ^"^^ '^'"''l^es, purchase orders, and 

user (step 900). The system accepts user input identifying a invoices, 

participant, service and document information generated by 20 standard measurements, date and time, location, classifi- 

the graphical interface (step 901). ™ • • /- • ' • ^ 

VT c J 1 • 1 . ^ • ^ lius iniormation is represented as an extensible, pubuc 

Next, any referenced logical structures, interpretation . jvx*t u -u- ui 1 u . 

information, document definitions and/or service definitions '''f building blocks that companies can customize 

are retrieved from the repository in response to user input via ^""^ ^^^^^^P appUcations quickly. Atomic 

the graphical user interface (step 902). In the next step, any CBLelements implement industry messaging standards and 

complementary business interface definitions or components conventions such as standard ISO codes for countries, 

of business interface definitions are accessed from other currencies, addresses, and time. Low level CBL semantics 

participants in the network selected via user input, by ^^"^^ ^*so come from analysis of proposed metadata frame- 
customized search engines, web browsers or otherwise (step 30 ^^rks for Internet resources, such as Dublin Core. 

903). A document definition for the participant is created The next level of elements use these building blocks to 

using the information gathered (step 904). The translators implement the basic business forms such as those used in 

for the document to host and host to document mappers are X12 EDI transactions as well as those used in emerging 

created by the compiler (step 905). Host architecture data Internet standards such as OTP (Open Trading Protocol) and 
structures corresponding to the definition are created by the 35 OBI (Open Buying on the Internet). 

compiler (step 906), and the business interface definition CBL's focus is on the functions and information that are 

which has been created is posted on the network, such as by common to all business domains (business description 

posting on a website or otherwise, making it accessible to primitives like companies, services, and products; business 

other nodes in the network (step 907). forms like catalogs, purchase orders, and invoices; standard 

Business interface definitions tell potential trading part- measurements, date and time, location, classification codes), 

ners the online services the company offers and which CBL builds on standards or industry conventions for seman- 

documents to use to invoke those services. Thus, the services tics where possible (e.g., the rules that specify "day/month/ 

are defined in the business interface definition by the docu- year" in Europe vs "month/day/year" in the U.S. are 
ments that they accept and produce. This is illustrated in the 45 encoded in separate CBL modules), 

following firagment of an XMLservice definition set forth as The CBL is a language that is used for designing apph- 

LISTING 5, in the file named LISTING COMBINED.txt in cations. It is designed to bridge the gap between the "docu- 

the accompanying computer program listing appendix. ment world'* of XML and the "programming worid" of JAVA 

This XML fragment defines a service consisting of two or other transaction processing architectures. Schema 

transactions, one for taking orders and the other for tracking embodies a philosophy of "programming with documents" 

them. Each definition expresses a contract or promise to in which a detailed formal specification of a document type 

carry out a service if a valid request is submitted to the is the master source from which a variety of related forms 

specified Web address. The Order service here requires an can be generated. These forms include XML DTDs for CBL, 
input document that conforms to a standard "po.dtd" Docu- 55 JAVA objects, programs for converting XML instances to 

ment Type Definition located in the repository, which may and from the corresponding JAVA objects, and supporting 

be local, or stored in an industry wide registry on the documentation. 

network. If a node can fulfill the order, it will return a The CBL creates a single source from which almost all of 
document conforming to a customized "invoice.dtd" whose the pieces of a system can be automatically generated by a 
definition is local. In effect, the company is promising to do compiler. The CBL works by extending SGML/XML, which 
business with anyone who can submit a Purchase Order that is normally used to formally define the structures of par- 
conforms to the XML specification it declares. No prior ticular document types, to include specification of the 
arrangement is necessary. semantics associated with each information element and 
The DTD is the formal specification or grammar for 55 attribute. The limited set of (mostly) character types in 
documents of a given type; it describes the elements, their SGML/XML can be extended to declare any kind of 
attributes, and the order in which they must appear. For datatype. 
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Here is a fragmenl from the CBL definition for the 
"datetime" module: 



<! — datetime. mod Version: 1.0 — > 

<t— Copyright 1998 Veo Systems, Inc ~> 

<\ ELEMENT year (#PCDArA)> 
<! ATTLIST year 

schema CDATA #FIXED "urn;x-veosystcms:stds:iso:8601:3.8" 

> 

<! ELEMENT month (#PCDATA)> 
<:! ATTLIST month 

schema CDATA #FIXED "urn :x- veosy stems :8tda:iso:8601:3. 12" 



10 



In this fragment, the ELEMENT "year" is defined as 
character data, and an associated "schema" attribute, also 
character data, defines the schema for "year** to be section 
3.8 of the ISO 8601 standard. 

This "datetime" CBL module is in fact defined as an 
instance of the Schema DTD. First, the module name is 
defined. Then the "datetime" element ^TEAR" is bound to 
the semantics of ISO 8601: 



<\ DOCTVPE SCHEMA SYSTEM **schema.dtd"> 
<SCHEMA> <Hl>Datc and Time Modulc<^l> 

<ELEMNTryPE NAME-"year" DAIATYPE-"YEAR"> <MODEL> 
<STRING 

DATArYPE=-YEAR"> <ySTRING> </MODEL> 
<ATTDEF NAME-:schcma:iso8601" DArArYPE»"CDArA"> 
<FIXED>3.8 

Gregorian calendar^IXED> </ATTDEF> </ELEMENTTYPE> 
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The example market participant and service modules 
above are also stored in the CBL repository. 

In FIG. 10, an Airbill 1000 is being defined by custom- 
izing a generic purchase order DTD 100, adding more 
specific information about shipping weight 1002. The ^ 
generic purchase order 1001 was initially assembled from 
the ground up out of CBL modules for address, date and 
time, currency, and vendor and product description. Using 
CBL thus significantly speeds the development and imple- 
mentation of XML commerce applications. More 45 
importantly, CBL makes it easier for commercial applica- 
tions to be interconnected. 

In the CBL, XML is extended with a schema. The 
extensions add strong-typing to XML elements so that 
content can be readily validated. For example, an element 50 
called <CPU_clock_speed> can be defined as an integer 
with a set of valid values: {100, 133, 166, 200. 233, 266 
Mhz.}. The schema also adds class-subclass hierarchies, so 
that information can be readily instantiated from class 
definitions. A laptop, for instance, can be described as a 
computer with additional tags for features such as display 
type and battery life. These and other extensions facilitate 
data entry, as well as automated translations between XML 
and traditional Object-Oriented and relational data models. 

Thus the completed BID is run through the compiler 
which produces the DTDs for the actual instance of a 
participant and a service as outlined above, the JAVA beans 
which correspond to the logical structures in the DTD 
instances, and transformation code for transforming from 
XML to JAVA and from JAVA to XML. In alternative 
systems documentation is also generated for display on a 65 
user interface or for printing by a user to facilitate use of the 
objects. 



For the example market participant and service DTDs set 
forth above, the JAVA beans generated by the compiler are 
set forth (with some redactions for conciseness) as LISTING 
6, in the file named USTING COMBINED.txt in the 
accompanying computer program listing appendix. 

In addition to the JAVA beans set forth above, transfor- 
mation code is produced for translating from JAVA to XML 
and XML to JAVA as set forth as LISTING 7, in the file 
named LISTING COMBINED.txt in the accompanying 
computer program listing appendix. 

Finally, the XML document instance(s) generated at run 
time according to the model above for one example is set 
forth as USTING 8, in the file named USTING COM- 
BINED.txt in the accompanying computer program listing 
appendix. 

Using the tools along with a BID composer application, 
which provides a drag, drop and forms editing user interface, 
a developer is able to create a business interface definition 
and to produce a well formed, valid business interface 
definition in the form of an XML document. Thus, the 
example run time instance is a business interface definition 
for an ordering service for IBM to be used by Ingram Micro 
and others to order laptop computers from IBM. (There is no 
relationship between the applicant and IBM or Ingram 
Micro). Utilizing these processes, a user is able to build a 
system that allows for programming of a business interface 
using the documents defined according to the present inven- 
tion. 

The role of CBL and the BID processor of the present 
invention in an XML/JAVA environment can be further 
understood by the following explanation of the processing of 
a Purchase Order. 

Company A defines its Purchase Order document type 
using a visual programming environment that contains a 
library of CBL .DTDs and modules, all defined using 
common business language elements so that they contain 
data type and other interpretation information. Company A*s 
PO might just involve minor customizations to a more 
generic "transaction document" specification that comes 
with the CBL library, or it might be built from the ground up 
from CBL modules for address, date and time, currency, etc. 

The documentation for the generic "transaction docu- 
ment" specification (such as the transact.dtd set out above) 
typifies the maimer in which CBL specifications are built 
from modules and are interlinked with other CBL DTDs. 

A compiler takes the purchase order definition and gen- 
erates several different target forms. All of these target forms 
can be derived through "tree to tree** transformations of the 
original specification. The most important for this example 
are: 

(a) the XML DTD for the purchase order. 

(b) a JAVA Bean that encapsulates the data structures for 
a purchase order (the JAVA classes, arguments, 
datatypes, methods, and exception structures are cre- 
ated that correspond to information in the Schema 
definition of the purchase order). 

(c) A "marshaling" program that converts purchase orders 
that conform to the Purchase Order DTD into a Pur- 
chase Order JAVA Bean or loads them into a database, 
or creates HTML (or an XSL style sheet) for displaying 
purchase orders in a browser. 

(d) An "unmarshaling" program that extracts the data 
values from Purchase Order JAVA Beans and converts 
them into an XML document that conforms to the 
Purchase Order DTD. 

Now, back to the scenario. A purchasing application 
generates a Purchase Order that conforms to the DTD 
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Specified as the service interface for a supplier who accepts 
purchase orders. 

The parser uses the purchase order DTD to decompose the 
purchase order instance into a stream of information about 
the elements and attribute values it contains. These "prop- 5 
erty sets" are then transformed into corresponding JAVA 
event objects by wrapping them with JAVA code. This 
transformation in effect treats the pieces of marked-up XML 
document as instructions in a custom programming language 
whose grammar is defined by the DTD. These JAVA events 
can now be processed by the marshaling applications gen- 
erated by the compiler to "load" JAVA Bean data struaures. 

Turning the XML document into a set of events for JAVA 
applications to process, is unlike the normal model of 
parsing in which the parser output is maintained as an 
internal data structure and processing does not begin until 
parsing completes. The event based processing, in response 
to the BID definitions, is the key to enabling the much richer 
functionality of the processor because it allows concurrent 
document application processing to begin as soon as the first 
event is emitted, 

JAVA programs that "listen for" events of various types 
are generated from the Schema definition of those events. 
These listeners are programs created to carry out the busi- 
ness logic associated with the XML definitions in the CBL; ^5 
for example, associated with an "address" element may be 
code that validates the postal code by checking a database. 
These listeners "subscribe" to events by registering with the 
document router, which directs the relevant events to all the 
subscribers who are interested in them. 

This publish and subscribe architecture means that new 
listener programs can be added without knowledge by or 
impact on existing ones. Each listener has a queue into 
which the router directs its events, which enables multiple 
listeners can handle events in parallel at their own pace. 

For the example purchase order here, there might be 
listeners for: 

the purchase order, which would connect it to an order 
entry program, 

product descriptions, which might check inventory, 40 
address information, which could check Fed Ex or other 

service for delivery availability, 
buyer information, which could check order history (for 
creditworthiness, or to offer a promotion, or similar 
processing based on knowing who the customer is). 45 
Complex listeners can be created as configurations of 
primitive ones (e.g., a purchase order listener may contain 
and invoke these listeners here, or they may be invoked on 
their own). 

FIG. 11 illustrates the market maker node in the network 50 
of FIG. 1. The market maker node includes the basic 
structures of the system of FIG, 3, including a network 
interface 1101, a document parser 1102, a document to host 
and host to document translator 1103, and a front end 1104, 
referred to as a router in this example. The market maker 55 
module 1105 in this example includes a set of business 
interface definitions, or other identifiers sufiScient to support 
the market maker function, for participants in the market, a 
CBL repository, and a compiler all serving the participants 
in the market. The router 1104 includes a participant registry 60 
and document filters which respond to the events generated 
at the output of the translator and by the parser to route 
incoming documents according to the participant registry 
and according to the element and attribute filters amongst 
the listeners to the XML event generators. Thus, certain 65 
participants in the market may register to receive documents 
that meet prespecifled parameters. For example, input docu- 



,912 B2 

24 

ments according to a particular DTD, and including an 
attribute such as numbers of products to be purchased 
greater than a threshold, or such as a maximum price of a 
document request to be purchased, can be used to filter 
documents at the router 1104. Only such documents as 
match the information registered in the participant registry at 
the router 1104 are then passed on to the registered partici- 
pant. 

The router 1104 may also serve local host services 1105 
and 1106, and as such act as a participant in the market as 
well as the market maker. Typically, documents that are 
received by the router 1104 are traversed to determine the 
destinations to which such documents should be routed, 
there again passed back through the translator 1103, if 
necessary, and out the network interface 1101 to the respec- 
tive destinations. 

The market maker is a server that binds together a set of 
internal and external business services to create a virtual 
enterprise or trading community. The server parses incoming 
documents and invokes the appropriate services by, for 
example, handing off a request for product data to a catalog 
server or forwarding a purchase order to an ERP system. The 
server also handles translation tasks, mapping the informa- 
tion from a company's XML documents onto document 
formats used by trading partners and into data formats 
required by its legacy systems. 

With respect to the service definition above, when a 
company submits a purchase order, the XML parser in the 
server uses the purchase order DTD to transform the pur- 
chase order instance into a stream of information events. 
These events are then routed to any application that is 
programmed to handle events of a given type; in some cases, 
the information is forwarded over the Internet to a different 
business entirely. In the purchase order example, several 
applications may act on information coming from the parser: 

An order entry program processes the purchase order as a 
complete message; 

An ERP system checks inventory for the products 
described in the purchase order; 

A customer database verifies or updates the customer's 
address; 

A shipping company uses the address information to 

schedule a delivery 
A bank uses the credit card information to authorize the 

transaction. 

Trading partners need only agree on the structure, content, 
and sequencing of the business documents they exchange, 
not on the details of APIs. How a document is processed and 
what actions result is strictly up to the business providing the 
service. This elevates integration from the system level to 
the business level. It enables a business to present a clean 
and stable interface to its business partners despite changes 
in its internal technology implementation, organization, or 
processes. 

FIGS. 12, 13 and 14 illustrate processes executed at a 
market maker node in the system of FIG. 11. In FIG. 12, an 
input document is received at the network interface from an 
originating participant node (step 1200). The document is 
parsed (step 1201). The document is translated to the format 
of the host, for example XML to JAVA (step 1202). The host 
formatted events and objects are then passed to the router 
service (step 1203). The services registered to accept the 
document according to the document type and content of the 
document are identified (step 1204). The document or a 
portion of the document is passed to the identified services 
(step 1205). As service is performed in response to the 
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document content (step 1206). The output data of the service If an error is found, then the parser sends the docunaent back 

is produced (step 1207). The output is converted to the to the communication agent 1500. A business interface 

document format, for example from a JAVA format to an definition compiler BIDC 1507 acts as a compiler for 

XML format (step 1208). Finally, the output document is business interface definition data. The DTD file for the XML 

sent to a participant node (step 1209). 5 parser, JAVA beans corresponding to the DTD file, and 

The registration service is one such function which is translation rules for translating DTD files to JAVA beans are 

managed by the router. Thus, a market participant document created by compUing the BID data. An XML instance is 

is accepted at the network interface as shown in FIG. 13 JAVA uKtance by referring to these tools. Thus 

(step 1300). The market participant document is stored in the '^^^^^'}^^^ ^^""^^ ?™ documents 1508 and 

business interface definition repository (step 1301) for the lo P^,^,^^f ^^^^^^ documents which correspond 1509. The 

market maker node. In addition, the document is parsed .'?h^^v^^ the processor 1502 which 

/* iini\ A ^ 1.-1** *u translates them into the JAVA format. In a preferred system, 

(step 1302). The pai^d document is Uanslated into the j^^^ documents which have the same status as the docu- 

format of the host (step 1303) Neja, the document is pa^^^^ ^,^t type definitions received in the XML format are 

to the router service (step 1304). The router service mcludes produced. The JAVA beans are passed to the document 

a listener which identifies the registration service as the 15 jo^ter 1503. The document router 1503 receives the JAVA 

destination of the document according to the document type beans and passes the received class to the appropriate 

and content (step 1305). The document or elements of the document service using a registry program, for example 

document are passed to the registration service (step 1306). using the event listener architecture described above. The 

In the registration service, the needed service specifications document service 1504 which receives the document in the 

are retrieved according to the business interface definition 20 form of JAVA beans from the router 1503 acts as the 

(step 1307). If the service specifications are gathered, at step interface to the enterprise solution software. This includes a 

1308, the router service filters are set according to the registry service 1510 by which listeners to XML events are 

business interface definition and the service specifications coupled with the incoming data streams, and a service 

(step 1309). Registration acknowledgment data is produced manager 1511 to manage the routing of the incoming 

(1310). The registration acknowledgment data is converted 25 documents to the appropriate services. The document ser* 

to a document format (step 1311). Finally, the acknowledg- vice manager 1511 provides for administration of the reg- 

ment document is sent to the participant node indicating to istry service and for maintaining document consistency and 

the participant that is successfully registered with the market the like. 

maker (step 1312), The document service communicates with the back end 

The process at step 1307 of gathering needed service 30 system using any proprietary API, or using such more 

specificationsisillustratedforoneexampleinFIG. 14. This common forms as the CORBA/COM interface or other 

process begins by locating a service business interface architectures. 

definition supported by the market participant (step 1400). FIG. 16 provides a heuristic diagram of the market maker 
The service definition is retrieved, for example by an E-mail and market participant structures according to the present 
transaction or web access to repository node (step 1401). 35 invention. Thus, the electronic commerce market according 
The service specification is stored in the BID repository to the present invention can be logically organized as set 
(step 1402). The service business interface definition docu- forth in FIG. 16. At the top of the organization, a market 
ment is parsed (step 1403), The parsed document is trans- maker node 1600 is established. The market maker node 
lated into the format of the host (step 1404), Host objects are includes resources that establish a marketplace 1601, Sucb 
passed to the router service (step 1405). The registration 40 resources include a market registry service and the like, 
service is identified according to the document type and Businesses 1602 register in the marketplace 1601 by pub- 
content (step 1406). Finally, the information in the service lishing a business interface definition. The business interface 
business interface definition document is passed to the definition defines the services 1603 for commercial trans- 
registration service (step 1407) for use according to the actions in which the businesses will participate. The trans- 
process of FIG. 13. 45 actions 1604 and services 1603 use documents 1605 to 

FIG. 15 illustrates the processor, components and define the inputs and outputs, and outline the commercial 
sequence of processing of incoming data at market maker relationship between participants in the transaction. The 
node according to the present invention. The market maker documents have content 1606 which carries the particulars 
node includes a communication agent 1500 at the network of each transaction. The manner in which the content is 
interface. The communication agent is coupled with an 50 processed by the participants in the market, and by the 
XML parser 1501 which supplies events to an XML pro- market maker is completely independent of the document 
cessor 1502. The XML processor supplies events to a based electronic commerce network which is established 
document router. The document router feeds a document according to the present invention. Overall, a robust, 
service 1504 that provides an interface for supplying the scalable, intuitive structure is presented for enabling elec- 
received documents to the enterprise solution software 1505 55 tronic commerce on communication networks is provided, 
in the host system. The communication agent 1500 is an Thus, the present invention in an exemplary system 
Internet interface which includes appropriate protocol stacks provides a platform based on the XML processor and uses 
supporting such protocols as HTTP, SMTP, FTP, or other XML documents as the interface between loosely coupled 
protocols. Thus, the incoming data could come in an XML business systems. The documents are transferred between 
syntax, an ASCII data syntax or other syntax as suits a 60 businesses and processed by participant nodes before enter- 
particular communication channel. All the documents ing the company business system. Thus the platform enables 
received in non-XML syntaxes are translated into XML and electronic commerce applications between businesses where 
passed the XML parser. A translation table 1506 is used to each business system operates using different internal com- 
support the translation from non-XML form into XML form, merce platforms, processes and semantics, by specifying a 

The converted documents are supplied to the parser 1501. 65 common set of business documents and forms. 

The XML parser parses the received XML document According to the present invention, virtual enterprises are 

according to the document type definition which matches it, created by interconnecting business systems and service, are 
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primarily defined in terms of the documents (XML-encoded) 
that businesses accept and generate: 
"if you send me a request for a catalog, I will send you a 
catalog: 

"if you send me a purchase order and I can accept it, I will 5 
send you an invoice". 

The foregoing description of a preferred embodiment of 
the invention has been presented for purposes of illustration 
and description. It is not intended to be exhaustive or to limit 
the invention to the precise forms disclosed. Obviously, 
many modifications and variations will be apparent to prac- 
titioners skilled in this art. It is intended that the scope of the 
invention be defined by the following claims and their 
equivalents. 

What is claimed is: 

1. Apparattis for establishing participant interfaces for 15 
transactions executed on a system including a network 
interface and a data processing resources which execute a 
transaction processes of the transactions according to a 
transaction processing architecture; comprising: 

programs of instructions executable by the system, stored 20 
on a medium accessible by the system, providing tools 
to build a definition of a participant interface for a 
participant in a particular transaction, the definition of 
a participant interface including a definition of an input 
document for the participant and a definition of an 
output document for the participant, the definitions of 
the input and output documents comprising respective 
machine-readable descriptions of sets of storage units 
and logical structures for the sets of storage units; and 

programs of instructions executable by the system, stored 
on a medium accessible by the system and responsive ^0 
to the definitions of the input and output documents, to 
compile data structures corresponding to the sets of 
storage units and logical structures of the input and 
output documents compliant with the transaction pro- 
cessing architecture, to compile instructions executable 35 
by the system to translate the input document to the 
corresponding data structures, and to compile instruc- 
tions executable by the system to translate output of the 
transaction processes into the sets of storage units and 
logical structures of the output document. 

2. The apparatus of claim 1, wherein the tools to build a 
definition of a participant interface include instructions 
executable by the system to access elements of the definition 
from a repository, the repository storing a library of logical 
structures, and interpretation information for logic structures 
used to build interface descriptions. 45 

3. The apparatus of claim 2, wherein the repository 
includes interpretation information specifying measure- 
ments of products subject of transactions. 

4. The apparatus of claim 2, wherein the repository 
includes interpretation information specifying costs of prod- 50 
ucts subject of transactions. 

5. The apparatus of claim 2, wherein the repository 
includes interpretation information specifying features of 
products subject of transactions. 

6. The apparatus of claim 2, wherein the repository 
includes interpretation information specifying financial 
terms of transactions. 

7. The apparatus of claim 2, wherein the repository 
includes interpretation information specifying terms of ship- 
ment for products subject of transactions. 

8. The apparatus of claim 2, wherein the repository stores 
definitions of documents comprising logic structures. 

9. The apparatus of claim 8, wherein the definition of one 
of the input and output documents includes a reference to a 
document type in the repository. 

10. The apparatus of claim 1, wherein the tools to build a 65 
definition of a participant interface include instructions 
executable by the system 
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to access a definition of another participant interface for 
a complementary transaction, the accessed definition 
including a definition of an input document for the 
complementary transaction, and a definition of an out- 
put document for the complementary transaction; and 

to establish the definition of the participant interface by 
including the definition of the output document of the 
complementary transaction as the definition of the input 
document of the interface being built. 

11. The apparatus of claim 10, wherein the tools to build 
a definition of a participant interface include instructions 
executable by the system 

to include the definition of the input document of the 
complementary transaction as the definition of the 
output document of interface being built. 

12. The apparatus of claim 1, wherein the tools to build a 
definition of a participant interface include instructions 
executable by the system to build a document compliant 
with a definition of a participant interface document includ- 
ing logical structures for storing an identifier of a particular 
transaction, and at least one of definitions and references to 
definitions of input and output documents for the particular 
transaction. 

13. The apparatus of claim 1, wherein the tools to build a 
definition of a participant interface include instructions 
executable by the system to build a document compliant 
with a definition of a participant interface document includ- 
ing logical structures for storing an identifier of the partici- 
pant interface, and for storing at least one of specifications 
and references to specifications of a set of one or more 
transactions supported by the participant interface. 

14. The apparatus of claim 13, wherein the a document 
compliant with a definition of a participant interface docu- 
ment includes a reference to a machine-readable specifica- 
tion of a particular transaction, and the specification of the 
particular transaction includes a document including logical 
structures for storing at least one of definitions and refer- 
ences to definitions of input and output documents for the 
particular transaction. 

15. The apparatus of claim 1, wherein the storage units 
comprise parsed data. 

16. The apparatus of claim 15, wherein the parsed data in 
at least one of the input and output documents comprises: 

character data encoding text characters in the one of the 

input and output documents, and 
markup data identifying sets of storage units according to 

the logical structure of the one of the input and output 

documents. 

17. The apparatus of claim 16, wherein at least one of the 
sets of storage units encodes a plurality of text characters 
providing a natiu'al language word. 

18. The apparatus of claim 15, wherein the specification 
includes interpretation information for at least one of the sets 
of storage units identified by the logical structure of at least 
one of the input and output documents, encoding respective 
definitions for sets of parsed characters. 

19. The apparatus of claim 15, wherein the storage units 
comprise unparsed data. 

20. The apparatus of claim 1, wherein data structures 
corresponding to the sets of storage units and logical struc- 
tures of the input and output documents include program- 
ming objects including variables and methods according to 
the variant transaction processing architecture. 

21. The apparatus of claim 1, wherein the variant trans- 
action processing architectures of the transaction process 
includes comprises a process compliant with an interface 
description language. 

22. The apparatus of claim 1, wherein the definitions of 
the input and output documents comprise document type 
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definitions compliant with a standard Extensible Markup complementary transaction as the definition of the input 

Language XML. document of the interface being built. 

23. Apparatus for establishing participant interfaces for 33, The apparatus of claim 32, wherein the tools to build 
transactions executed on a system; comprising: ^ definition of a participant interface include instructions 

memory storing data and programs of instructions; 5 executable by the system 

a data processor coupled to the memory which executes to include the definition of the input document of the 

the programs of instructions; wherein the programs of complementary transaction as the definition of the 

instructions include output document of interface being built, 

tools to build a definition of a participant interface for 34, xhe apparatus of claim 23, wherein the tools to build 

a partiapant in a particular transaction, the defimtion 10 ^ definition of a participant interface include instructions 

of a participant uiterface includmg a defimtion of an executable by the system to build a document compliant 

input document for the participant and a definition of ^th a definition of a participant interface document includ- 

an output document for the participant, the defini- ing logical structures for storing an identifier of a particular 

tions of the input and output documents comprising transaction, and at least one of definitions and references to 

respective machine-readable descriptions of sets of 15 definitions of input and output documents for the particular 

storage units and logical structures for the sets of transaction. 

storage units; and 35 -phe apparatus of claim 23, wherein the tools to build 

a compiler, responsive to the definitions of the input a definition of a participant interface include instructions 

and output documents, to compile data structures executable by the system to build a document compliant 

corresponding to the sets of storage units and logical 20 ^-^j^ ^ definition of a participant interface document includ- 

structures of the input and output documents com- logical structures for storing an identifier of the partici- 

pliant with the transaction processing architecture, to p^nt interface, and for storing at least one of specifications 

compile instructions executable by the system to ^nd references to specifications of a set of one or more 

translate the input document to the corresponding transactions supported by the participant interface, 

data structures, and to compile instructions exccut- 25 3^ -j^^ apparatus of claim 35, wherein the a document 

able by the system to translate output of the trans- compliant with a definition of a participant interface docu- 

action processes into the sets of storage units and ment includes a reference to a machine-readable specifica- 

logical structures of the output document. tion of a particular transaction, and the specification of the 

24. The apparatus of claim 23, including a repository particular transaction includes a document including logical 
stored in memory accessible by the data processor, and 30 structures for storing at least one of definitions and refer- 
wherein the tools to build a definition of a participant ences to definitions of input and output documents for the 
interface include instructions executable by the system to particular transaction. 

access elements of the definition from the repository, the 37. The apparatus of claim 23, wherein the storage units 

repository storing a library of logical strucmres, and inter- comprise parsed data. 

pretation information for logic structures used to build 35 38. The apparatus of claim 37, wherein the parsed data in 

interface descriptions. at least one of the input and output documents comprises: 

25. The apparatus of claim 24, wherein the repository character data encoding text characters in the one of the 
includes interpretation information specifying measure- i^put and output documents, and 

ments of products subject of transactions. , 1 . -j . r • . c . j- . 

26. The apparatus of claim 24, wherein the repository "^^'^f data identifying sete of storage umts according to 
includes interpretation information specifying costs of prod- '° ^""^^^^ ^^^^^ of ^°P^' °^tP^* 
ucts subject of transactions. documents. , . . 

27. The apparatus of claim 24, wherein the repository ^9. The apparatus of clarni 38, wherem at least one of the 
includes interpretation information specifying features of ^^^^ of storage units encodes a plurality of text characters 
products subject of transactions. providmg a natural language word. 

28. The apparatus of claim 24, wherein the repository ^O. The apparatus of claim 37. wherein the specification 
includes interpretation information specifying financial mcludes interpretation information for at least one of the sets 
terms of transactions. storage units identified by the logical strucmre of at least 

29. The apparatus of claim 24. wherein the repository ^f the input and output documents, encoding respective 
includes interpretation information specifying terms of ship- definitions for sets of parsed characters. 

ment for products subject of transactions. so 41. The apparatus of claim 37, wherem the storage units 

30. The apparatus of claim 24, wherein the repository comprise unparsed data. 

stores definitions of documents comprising logic structures. 42. The apparatus of claim 23, wherein data structures 

31. The apparatus of claim 30, wherein the definition of corresponding to the sets of storage units and logical struc- 
one of the input and output documents includes a reference ^^^^ of the input and output documents include program- 
to a document type in the repository. 55 obiccis including variables and methods according to 

32. The apparatus of claim 23, wherein the tools to build variant transaction processing architecture. 

a definition of a participant interface include instnictions 43. The apparatus of claim 23. wherem the variant trans- 
executable by the system action processing architectures of the transaction process 
to access a definition of another participant interface for ^^Pff " P'"'^*^ '"'^rf"^ description 
a complementary transaction, the accessed definition 4^ f£e apparatus of claim 23, wherein the definitions of 
mcludmg a definition of an input document for the j„p„, ^^p^, documents comprise document type 
complementary transaction, and a defimUon of an out- definitions compliant with a standard Extensible Markup 
put document for the complementary transaction; and Language XML. 
to establish the definition of the participant interface by 
including the definition of the output document of the ***** 
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